home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 2 / CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso / magazine / amiga_e / amigae.july.archive / 000009_crash!kirk.safb.af.mil!BWILLS_Wed, 7 Jul 93 06:02:53 PST.msg < prev    next >
Text File  |  1993-08-31  |  7KB  |  175 lines
  1. Received: by bkhouse.cts.com (V1.16/Amiga)
  2.     id AA00000; Wed, 7 Jul 93 06:02:53 PST
  3. Received: from kirk.safb.af.mil by crash.cts.com with smtp
  4.     (Smail3.1.28.1 #15) id m0oDYk1-0000CHC; Wed, 7 Jul 93 05:36 PDT
  5. Message-Id: <m0oDYk1-0000CHC@crash.cts.com>
  6. Date: 7 Jul 93 07:33:00 CST
  7. From: "Barry D. Wills" <BWILLS@kirk.safb.af.mil>
  8. To: "amigae" <amigae@bkhouse.cts.com>
  9. Subject: re:  The Future of E (with a minor digression)
  10.  
  11. Here are excerpts from correspondence I'd like to pass on which refer to the
  12. news about the next E upgrade (and a few odds and ends.)  -- Barry
  13.  
  14. --------------------------------------------------------------------------------
  15.  
  16. [letter #1]
  17.  
  18. - error reconstruction: EC now exactly pinpoints the character that
  19.   caused the error
  20. - optimisations: EC is now 20% to 70% faster than EC2.1b
  21. - optimisations in code-generation.
  22. - reduction in EC's memory consumption with 40% to 50%
  23. - default arguments a la C++
  24. - kick 3.0 modules
  25. - object inheritance (without methods, for now)
  26. - multiple returnvalues and multiple-value assignments
  27. - symbolhunks for use with profiler
  28. - .o to .m file converter (for assembly)
  29. - numerous small bugs fixed and small enhancements made
  30.  
  31. these are all already implemented, that what is yet to come
  32. is also quite stunning
  33.  
  34. this info was supposed to be on the list soon, just wait and see.
  35.  
  36. >> Oh, one more thing I was interested in seeing implemented:  initialization of
  37. >> variables at time of declaration, like:
  38. >>   DEF ptr : PTR TO CHAR = NIL  /* gives me 'Superfluous items' message */
  39.  
  40. you don't need 2.5 for this, try in v2.1b:
  41.  
  42. DEF ptr = NIL : PTR TO CHAR
  43.  
  44. works for constants only. isn't this in the manual?
  45.  
  46. --------------------------------------------------------------------------------
  47.  
  48. [letter #2]
  49.  
  50. >> Hi, Wouter.  I could not find reference to "DEF mypointer=NIL:PTR TO somethin
  51. g
  52. >> in the manuals.  I resorted to the examples, though, and found just such an
  53. >> animal.  It was in a number of 2.0-only examples which I didn't bother readin 
  54. g
  55. >> 'cause I only got 1.3 (but not for long, heh-heh, 2.1 is in the mail and on c
  56. ourse
  57. >> to my home; yip-yip-yipee!  Now all I need is another hard drive, a younger
  58. >> mouse and joystick, an optical scanner, an 8 or 16 meg simm, a few more
  59. >> references, and a bigger room! :)
  60.  
  61. yeah ok... stick with 2.1 for now, and you'll be more than happy
  62.  
  63. >> So that's two undocumented features:  StringF() and variable initialization.
  64. >> (Just in case you want to keep track :)
  65.  
  66. oh yes. I'm making notes of these for the new manual.
  67.  
  68. >> I perused again and again your recent messages concerning E V2.5.  I'll tell
  69. >> you, I'm really anticipating the release!  It all looks fantastic, and you sa
  70. y 
  71. >> there're more goodies!  Well, I'm saving my pennies, so you can rest assured
  72. >> that you'll have at least one customer.
  73.  
  74. good!
  75. I'm implementing features now faster than you can say "E": just
  76. made "multiple return values" possible. very special.
  77.  
  78. --------------------------------------------------------------------------------
  79.  
  80. [letter #3]
  81.  
  82. >> >yeah ok... stick with 2.1 for now, and you'll be more than happy
  83. >> 
  84. >> Little choice since money is limited, and my resources for the near future
  85. >> are tied up in an up and coming release of a programming language by some
  86. >> supernatural developer :)
  87.  
  88. huh? what? where? :-)
  89.  
  90. >> >I'm implementing features now faster than you can say "E": just
  91. >> >made "multiple return values" possible. very special.
  92. >> 
  93. >> Good God, man!  Is there no end to the madness?!  E-E-E-E-E-E-E-E-E.....!
  94.  
  95. [editor's note:  I figured this would give Wouter time to implement at least
  96. 15 more features :) ]
  97.  
  98. there's no end yet. there are some limits in language design, but
  99. as far as I'm going to take it, it will be ashtonishing.
  100. today I think I might give it a shot at full OO. dunno.
  101.  
  102. things are getting weirder every day. did I tell you that
  103. someone wants to graduate (write last thesis on university)
  104. on the subject of "E"? and _I_ didn't even manage to do so!
  105.  
  106. >> >- optimisations: EC is now 20% to 70% faster than EC2.1b
  107. >> 
  108. >> How on earth is this possible?!  With less memory consumption, no less!  Very
  109. >> impressive!
  110.  
  111. I applied some very heavy duty hashing techniques, and did some other
  112. hardcore optimising. some parts in v2.1b really were slow (not that anybody
  113. did notice)
  114.  
  115. >> >- 68881/2 support.
  116. >> >- some 020 support
  117. >> >- vast amount of highlevel modules for all sorts of tasks.
  118. >> 
  119. >> Unexpected, but certainly a centrifugal surprise! :)
  120. >> 
  121. >> >- other OO features (next to object inheritance)
  122. >> 
  123. >> Is EC gonna be smart enough to tell whether you want small fast procedural co
  124. de
  125. >> or big luxurious objects with methods?  I know my C++ compiler is a hog,
  126. >> regardless of whether I want to use OOP or not :(
  127.  
  128. um, say you write OO-less code, i.e. PROCs + OBJECTs without methods,
  129. the code will be as good as that of ec21b, and probably better.
  130. if you heavily use methods, you're bound to lose some speed,
  131. but in most cases this is very little.
  132.  
  133. >> >- module caching
  134. >> 
  135. >> What is this?  Like '030/'040 instruction caching?
  136.  
  137. nope. it's more like an "emodule.library" that hangs around in your
  138. system. say you have a gui-app that needs 10 modules. first time
  139. EC compiles them, they're all loaded from disk, second time, they're
  140. ALL directly available to EC. the library automatically flushes the
  141. modules it's loading when memory gets low. result: even for giant
  142. applications >100k, compile and link times can be kept <1sec.
  143.  
  144. >> >coming... reactions of general interest to this list!
  145. >> 
  146. >> I believe you already know my reaction.  *standing ovation*
  147.  
  148. you should then say so on the list, shouldn't you?
  149.  
  150. --------------------------------------------------------------------------------
  151.  
  152. [this letter]
  153.  
  154. So I'll say it again:  *standing ovation!!!*  What I've heard from a lot of you
  155. confirms my own opinion of E.  When I first got hold of E, it sat on a floppy
  156. for about 3 weeks until I got around to looking at it.  "Yeah, yeah," I said,
  157. "another PD programming language."  See, I was jaded by this time, being unable
  158. to find a language appealing enough and reliable enough.  Being a big fan of
  159. C++, I tried Lattice C++ (at $225!) and found it to be flakey.  I read about
  160. the compiler's features which concluded, "If these features haven't made you
  161. anxious to use E, I suggest you testdrive the compiler after reading this doc
  162. to "feel the power" yourself."  Some boast!  I had to take the challenge. 
  163. Well, I liked it enough to give up my current project in C++ at the time, 
  164. Fill - The Smart File Mover/Copier, and write it in E.  Then I decided to write
  165. EPP - an E Preprocessor, because I could see that major hole right away, no
  166. user modules; and I expected a long wait for the arrival of modules in the 
  167. language.  Well, I should have expected different, considering the speed of the
  168. compiler, the speed of response to my questions, and the personal interaction 
  169. Wouter has given us :)  I *was* a big fan of C and C++, but E V2.1b (BETA!) was
  170. far more wieldy, and more reliable.  And the user support has been incredible. 
  171. Sometimes I suspect there is more than one Wouter (more like 7 or 8, is that
  172. your secret? :)  I can't wait patiently for V2.5 to arrive!  But wait I will,
  173. chomping at the bit.
  174.  
  175. -- Barry